﻿<?xml version="1.0" encoding="utf-8"?>
<html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" MadCap:lastBlockDepth="2" MadCap:lastHeight="573" MadCap:lastWidth="1111">
    <head>
    </head>
    <body>
        <h1>Background</h1>
        <h2>Problem Statement</h2>
        <p>MxPlugin was created to provide a simple way of extending ImageCurator (another open-source project hosted on Codeplex - <a href="http://imagecurator.codeplex.com/" title="http://imagecurator.codeplex.com" alt="http://imagecurator.codeplex.com">http://imagecurator.codeplex.com</a> ). ImageCurator is a tool for researchers involved in image processing. This may be people who are developing new algorithms, or people who are using existing algorithms to analyse images like medical ultrasound scans.</p>
        <p>ImageCurator allows collections of images to be gathered into a dataset so they can be annotated and processed. The image processing functionality is performed by DLLs containing implementations of image processing algorithms. In this way, an additional algorithm can be made available to ImageCurator simply by developing a DLL containing its implementation. Typically, such algorithms have an existing implementation in C++ code and just need some form of wrapper code to make them available to ImageCurator - see <a href="http://c2.com/cgi/wiki?FacadePattern" title="explains Fascade Pattern" alt="explains Fascade Pattern" target="_blank">Fascade Pattern</a>.</p>
        <p>The main problem that MxPlugin needed to address was the difficulty of adding new algorithms without having to rebuild ImageCurator each time using the stub library of the newly acquired DLL. This was particularly important because it was envisaged that some researchers would just install the ImageCurator binaries on their machine and then use open-source tools to develop DLLs for their own image processing algorithms. Similarly, other researchers might want use ImageCurator in conjunction with DLLs obtained from third-parties without involving themselves in the onerous task of rebuilding any software. It was clear that rebuilding a new version of ImageCurator for each new algorithm that came along was impracticable. Instead, the DLLs would have to be completely decoupled from ImageCurator so they could be dynamically loaded at runtime without the need for any form of stub or static library.</p>
        <p>It was accepted that the problem of using software libraries to extend ImageCurator would be much easier to solve if all the code was written in a language like Java or C#. Unfortunately, the majority of image processing algorithms are implemented in C++. Therefore, implementing ImageCurator and its libraries in managed code would have incurred the additional complexity and performance hit of transitioning between managed and unmanaged code. It was for this reason that C++ was a natural choice for the development of ImageCurator and its libraries. The fact that the problem of implementing C++ libraries which could be dynamically loaded at runtime had been solved by technologies like COM and Corba gave us confidence that MxPlugin could be developed to do the same thing for ImageCurator.</p>
        <h2>Justification for creating MxPlugin</h2>
        <p>MxPlugin is not the first attempt to solve the problem of extending C++ applications with plugin software libraries. <a href="http://www.microsoft.com/com/default.mspx" target="_blank">Microsoft COM</a> and <a href="http://www.omg.org/gettingstarted/corbafaq.htm" target="_blank">OMG Corba</a> both provide  solutions to the problem of flexibly sharing C++ code modules on the same machine. Indeed, they also address the much wider issue of providing a scalable <a href="http://en.wikipedia.org/wiki/Middleware" target="_blank">middleware</a> that permits computer applications to work together over networks. However, this extensibility comes at a price for both these technologies are complex and notoriously difficult to master. Therefore, in the case of ImageCurator it would be a bit like using a sledgehammer to crack a nut. Similarly we considered a number of <a href="References/Refs-AlternativePlugins.htm">open-source alternatives</a>, but were unable to find any that were general purpose and had a significant following or usage.  Consequently, we seek to find a middle ground – a solution that is simple to use, has examples of non-trivial implementation and attracts a significant following in the developer community. Clearly, we have some way to go in terms of these last two requirements, but are convinced that with enough support this will happen over time.</p>
    </body>
</html>